home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.lang.c++
- Path: news.sprintlink.net!news1!news
- From: pbennett@acraline.com (Patrick Bennett)
- Subject: Re: Correctnes of BORLAND C++ RTTI Info in a multi threaded environment (WindowsNT)
- X-Nntp-Posting-Host: machine131.acraline.com
- Message-ID: <31518943.1725056@news.iquest.net>
- Sender: news@iquest.net (News Admin)
- Reply-To: pbennett@acraline.com
- Organization: Acraline Products
- X-Newsreader: Forte Agent .99c/16.141
- References: <315030FD.5898@isis.co.za>
- Date: Thu, 21 Mar 1996 17:01:08 GMT
-
- Itsik Rubin <yr@isis.co.za> wrote:
- >Hello, I am using Borland C++ Version 4.51 under Windows NT I am developping
- >a 32 bit application that is intended for Windows NT and I use extensively
- >multi threading as wellas the streaming mechanism provided in the Borland
- >class library. This is used for inter thread , inter process and inter
- >processor (over a LAN) communication. The developped system is required to
- >run continuously 24 hours a day 7 days a week. Approximatly once a day I run
- >into a problem where during the operation of the system a stream becomes
- >corrupted. When I make the following change to the opstream::WriteData
- >method inside objstrm.cpp I get logs in both places (marked 1 and 2). Based
- >on my observation the first _TYPENAME(strmr) is erronous whereas the second
- >one returns correct results. This points to problems within the RTTI
- >mechanism. The following questions (at least) need answer:
- > 1. Is typeinfo object, which is part of the Borland C++ RTTI, multi-thread safe?
- > 2. Has anyone else encounted this problem?
- > 3. Is there a fix for this problem?
- [snip]
-
- I ran into numerous problems with Borland and my multi-threaded apps
- whenever I threw exceptions. It seemed like every time I threw an
- exception the thread involved became, well, hosed. Early on, I
- thought it was a problem with one of the libraries/dll's that I was
- using, but after stumbling across a message from someone on CI$ about
- having to recompile the borland libraries for MT, I checked into it.
-
- If you're using the Borland TThread class (why not, it's there, it
- works [well kinda!]) as I was, this is one cause of the problems. If
- you look in the thread.cpp source you'll notice a few places that
- check for #ifdef __MT__ within the WIN32 section of the code, it MT
- isn't defined, it uses the WIN32 call CreateThread, if MT is defined
- then it uses the _beginthreadNT call. Of course, you have to MANUALLY
- recompile the BIDS library so that the right call is made!!!!!! If it
- uses CreateThread instead of _beginthreadNT then the RTL won't be
- properly set up for that thread. Below is a quote from the online
- help on _beginthreadNT:
-
- All multithread Windows NT programs must use _beginthreadNT or the
- _beginthreadfunction instead of the operating system thread-creation
- API function because these functions perform initialization required
- for correct operation of the run-time library functions. The
- _beginthreadNT function provides support for the operating system
- security. These functions are available only in the multithread
- libraries.
-
- OUCH!!!!
-
- If you look in bc45\source\classlib you'll find the makefile for
- recompiling the bids library (including the tthread classes) - read
- the makefile, it tells you how to compile for MT, DLL's, etc..
-
- Hope this fixes your problem....
-
-
- -------------------------------------------
- Patrick Bennett
- Acraline Products, Inc.
- pbennett@acraline.com / CIS: 74103,2115
-